Developing software systems represents both great economic value and great cost. Software tools and development methodologies address these costs so as to increase the profits by reducing costs. Unfortunately, the costs often grow faster than the profits as systems grow large. The advent of software modeling represents one of the greatest opportunities to improve the profitable value of producing large software systems.
Industry effort has improved the level of detail and the ability to specify systems through models in recent years. These developments make the transformation of an idea into a software system more straightforward either because it is quicker or because it reduces the risk that mistakes and misunderstandings will cause waste. In the beginning, modeling consisted of little more than a visual representation corresponding exactly to programmatic elements. Several developments stand out: a standardized visual notation (the Object Management Group's (OMG) Unified Modeling Language™ or the UML™); a model-view paradigm in which a model element contains a comprehensive set of data about the programmatic elements and a set of view filters that emphasize important aspects of these elements; the increasing use of metadata or information about the information held on an element; and the increasing level of abstraction of the meaning of one element. Where in former times one model element represented one programmatic element, in an “analysis software model,” one model element can represent or imply a whole set of collaborating programmatic objects for its implementation, often through several layers of an architecture.
At first, metadata about the model element referred to concrete programmatic architectural issues. Each new architectural issue required additional properties to record its properties that reflected valid implementation choice. Eventually, during the standardization efforts needed to create the UML™, a generalized and extendable mechanism, known as tagged value pairs, was created by which the toolmakers could add arbitrarily named data. Many modeling tools use this concept, including Rational Rose™, Together™ from TogetherSoft, Power Designer™ from Sybase and GD-Pro™ from Embarcadaro Corp. The early specifications of the UML™ recognized the usefulness of tagged value pairs for uses such as code generation. While typing of tagged values was specifically excluded from the UML™, some modeling tools, such as Sybase Power Designer™ have implemented such extensions.
Codagen Technologies Corp has developed the notion of external properties and external property groups. While the external properties are analogous to tagged values, the external property groups link these external properties to model elements. As with tagged values, the external properties are stored within the model of the host modeling tool. The addition of external property groups avoids the limitation that any external property/tagged value must be unique.
Many tools provide code generation capabilities. Many of these use tagged values or external properties to alter the semantics of code generation. While other code generation systems exist, those using tagged values fall into three categories.
First, macro or wizard type generators resolve parameterized source code with existing tagged values when the code generation is applied to the model element. This technique requires manual reapplying the code generation wizard if and when the tagged values of the model element change.
Second, some modeling tools provide a scripting language used to concatenate source code or to resolve parameterized source code with model elements and their associated tagged values as an alternative way to generate source code. This technique allows for refinement or correction of the software model, including tagged values to be reflected in subsequent automatic code generations. Unfortunately, the abstraction is quite low, meaning that in order to specify the model to sufficient detail for code generation, the model must contain many programmatic details and many hard coded properties. This is similar to programming within the model, making the model fragile in the face of change and requiring extensive technical programming expertise as well as UML™ and tool expertise.
Third, Codagen Gen-it™ Architect implements the effect of any property in code templates rather than in the modeling tool, these templates being called Gen-it™ Parameterized Architecture Blueprints™. During the code generation process, the generator contextually examines the model and tagged values to generate code.
Another type of tool generates code or other development artefacts in a post-processing step. They add software technology specific information to an extract of the software model. For example, Object/Relational mapping tools generate the glue code for marshalling model elements to and from a relational database. Object-relational mapping is the process of transforming between object and relational modeling approaches and between the systems that support these approaches. These tools extract information about the model element from the UML™ modeling tool. This is combined with user-entered information and information extracted from existing artefacts, like a database diagram, to create integrated object-relational mappings. Some of these tools record user responses, facilitating further refinements and evolutions.
Since the advent of platforms, also known as operating systems, software systems have been developed in layers. At the simplest and earliest level, this means dividing code specific to an operating system and to a particular domain. Present-day complex software applications, development software, middleware, and frameworks require layering for success. It is not uncommon for an application to have layers for database access, user interface, domain logic, and technologies such as Enterprise JavaBeans™ from Sun Microsystems. Development within one layer is mainly independent from development in another.
Software modeling addresses layering by designating a model element as belonging to one or another layer. The level of abstraction is limited by the fact that at least one model element must be present for each architectural layer of the software system.
The current UML™ tools have a very restricted view of tagged values. They treat tagged values as an integral part of the software model and so store them in proprietary repositories. From the point of view of the modeling tools, all tagged values are equal. There is no differentiation or management between those related to the architectural layer for one technology or another or for one platform or another. Partitioning is possible only by logical grouping of the domain, implying model elements at each relevant logical group. Partitioning is impossible by technological layer or by platform layer within any one model element or model element type.